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of a message. In a contention bus or contention ring network, 
the output machine may transmit only when the network 
is quiet. The “token present” signal is replaced by a “network 
quiet” signal. In the ring network, the reception control 
section signals the transmission control section if it detects 
another token in the midst of its receipt of the message the 
transmission control section sent; this has its analogue in the 
collision detection capability of the contention network. In 
both cases, the LNI must abort transmission of its message 
and take corrective action. In the ring network this is an 
error condition, an exception; more than one control token 
is present in the ring. In the contention network, a collision 
is an expected event. Both situations can be handled by the 
LNI reporting the event to host software, which can attempt 
to restart a token on the ring, in the ring network case, or 
apply a retransmission backoff algorithm in the contention 
network case. 

A better solution for the contention network is to modify 
the transmission control section to execute a simple retrans¬ 
mission backoff algorithm in hardware. This requires that 
the entire message remain accessible to the transmission con¬ 
trol section without host intervention. The FIFO buffer 
cannot be used in this situation; a complete packet buffer 
which is not erased until the message has been successfully 
transmitted is an appropriate alternative. 

Two features of the ring network LNI’s transmission con¬ 
trol section are not needed in the contention bus network 
version: the data repeater which passes bits from the receive 
side of the LNI to its transmit side when the LNI is not 
transmitting a message, and the token generator which 
places a new token or connector onto a quiescent ring. Of 
course, the connector is a brief sequence of bits, and there 
is no good motivation to delete it from the beginning of 
messages transmitted by the contention bus version of the 
LNI. In fact, retention of the connector at the head of a 
message results in fewer changes to the input machine of 
the LNI. It can use its token/connector detector to signal 
the beginning of an incoming message. Its function remains 
the same, for the most part; extra connectors detected in 
the middle of a message indicate a collision, just as they do 
for the ring network version. However, in the contention 
bus network, because bits are not repeated from one LNI 
to another, there is no way to set the match/accept bits for 
the benefit of the transmitting- LNI, and the match/accept 
field of the message cannot be used. 

The signal conditioning section of the LNI undergoes an 
interesting transformation. For a contention ring network, 
of course, the signal conditioning section remains the same. 
However, for a contention bus network, the logic levels of 
the LNI must be converted to appropriate signal levels and 
waveforms for the coaxial cable of the bus. This is done in 
a two-step process. First, a cable transceiver is added to the 
configuration. To minimize impedence mismatches, reflec¬ 
tions, etc., the transceiver is located immediately adjacent 
to the network cable, and is often packaged separately from 
the LNI. 4 It is connected to the cable either directly, or via 


^This has become common practice in local area networking; the 
networking transmission medium is generally not brought into the 
racks, equipment bays, etc., of a host computer where it would be 
subject to accidental disconnection and other physical abuse that 
could disrupt the entire network. Instead, the connection point for 
a host is designed to be physically stable: a box on the wall, above 
a false ceiling, etc. 
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Fig. 8. A typical bus transceiver. The opto-isolators and isolated p"**' 
supply permit the drivers and receivers to be referenced to vf'i* 
ground; the cable, in turn, is grounded at only one point alont ■'* 
length, eliminating problems that would result if each transcehcr n-4 
the cable to local host ground. 


a short stub cable attached to the main cable via a tap. 
ond, since the transceiver is located adjacent to the ncl* ' 
bus cable, and the LNI is located next to its host, an arr"’ 
priate transmission scheme must be selected to span :'■» 
intervening distance. For distances up to 30 ft or so. ' '>”£ r 
ended” drivers and receivers will suffice. For better rclial - -- 
greater distances, or both, differential signals over a slm.-.: ■■*- 
twisted pair can be used—just as in the transmission nn-o- 5 
of the ring network itself. So, the signal conditioning ^ 
of the original LNI can be modified to interconnect tin’ 1 
and the cable transceiver. 

4) The Cable Transceiver: The care taken in the 
of a cable transceiver for a contention bus network *** 
strongly influence the overall reliability and perform^ 
of the network. Therefore, we conclude our case stu<i> 
examining a hypothetical contention bus cable trance-^ 
shown in Fig. 8, that is similar to one designed and buiH 
the CHAOS Network at the MIT Artificial Intelligence 
tory; it is typical of transceivers built for various conR-- 
bus networks. 

The cable transceiver performs the following functions 

1) transmission (cable driving); 

2) reception; 

3) power and ground isolation; 

4) collision detection; 

5) transceiver fault detection (“watchdog”). 

The first three of these constitute part of the signal 
tioning function described previously. 
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■j-tje basic design principle of the transceiver is that it must 
„ reS ent a high impedence to the bus except when it is trans¬ 
mitting and actually driving the bus. This is essential to the 
^ration of the contention bus network; a large number of 
l, ce ivers on the bus must not present impedence lumps or 
' a ny wa y interfere with a transceiver which is actively 
a'ansnut ting. 

yhe receiver must be able to detect and properly receive 
-^nals from the most distant point on the bus; in addition, 

. must be able to detect a colliding signal while its companion 
-ansmitter is itself driving the bus. This requirement impacts 
,i, e choice of an encoding scheme for data transmitted on 

■ bus. A number of data encoding schemes can be used, all 
which require that the transmitter be able to place the 

-ansmission medium in two distinct states. At first glance, 

■ might seem that three states could be used: the quiescent, 

. jh-impedence state, to indicate that no transmission is in 
-ogress, and two active driver states, for example +V and 
I'. However, with two active driver states, when two or 

-jore network nodes attempt to transmit simultaneously, 
re cable will be driven to different voltage levels at different 
mints. This has two effects. First, it places a severe load 
■n drivers. Second, it makes the detection of a colliding 
egnal more difficult than it needs to be. On the other hand, 
the transceiver drives the cable to some voltage to represent 
-ne signaling state, and represents the other signaling state 
?y not driving the cable, the problem of overloaded drivers 
eliminated, and the task of collision detection is greatly 
cmplified. Collision detection is accomplished looking at 
the bus during the transmitter’s quiescent state. Any signal 
rresent during that time must come from another transceiver, 
ind constitutes a collision. The transceiver can detect an 
morning signal with 20-dB attenuation, which corresponds 
■j about 1 km of the particular cable used. 

The transceiver must be able to cope with ground potential 
riferences at the various network hosts. Isolation is accom- 
rlished by high-speed optocouplers and an isolated power 
upply which enables the major circuit elements of the trans- 
river to be referenced to cable ground, rather than local 
tost ground. Finally, the fault detection, or watchdog 
■ucuit examines the output of the driver to guard against 
'unsceiver failures which drive the bus and disrupt the net¬ 
work. The signaling states used by the transceiver result in 
■ie driver being quiescent approximately 50 percent of the 
■Tie; if the driver remains on steadily for several bit-times, 
is deemed to. be faulty, and the fault detector disconnects 
; s power, which, of course, returns the driver to its high- 
-upedence state. 

>1 Complexity of the Local Network Interface: In its 
Nesent form, the LNI comprises about 350 TTL SSI and 
^S1 integrated circuits, apportioned as follows: 


PDP-11 full-duplex DMA 
Name table controller 
Name table cells (8 provided) 
Network-oriented portion 
Test and diagnostic 


OB")- 1|J 

of the signal 


^ count of 120 chips for the network-oriented portion of 
' ,e LNl, excluding the associative name table, is well within 
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the capabilities of current large-scale integration. As the 
field of local area networking matures, and standards are 
arrived at, it is likely that integrated circuit manufacturers 
will add local area network controllers to their product lines, 
to take their place alongside other LSI data communication 
chips which are already available, making high-performance 
local area network technology available at a very reasonable 
cost. 

V. Protocols for Local Area Networks 

As in long-haul networks, local area network protocols 
can be divided into two basic levels—low-level protocols 
and high-level protocols. At each level, the characteristics 
of local networks impact effects on protocol design and 
functionality. 

A. Low-Level Protocols 

The term low-level protocol identifies the basic protocols 
used to transport groups of bits through the network with 
appropriate timeliness and reliability. The low-level protocols 
are not aware of the meaning of the bits being transported, 
as distinct from higher level application protocols that use 
the bits to communicate about remote actions. Two aspects 
of local area networks have a very strong impact upon the 
design of low-level protocols. First, the high performance 
achievable purely through hardware technology enables the 
simplification of protocols. Second, low-level protocols 
must be designed to take advantage of and preserve the special 
capabilities of local networks, so that these capabilities can 
be utilized, in turn, by higher level application protocols. 
We will explore these two issues in this section. 

1) Simplicity: Local area networks must support a wide 
variety of hosts, from dedicated microprocessors to large 
time-sharing systems. The existence of extremely simple 
hosts (such as microprocessor-based intelligent terminals, 
or even microprocessor printer controllers) leads to a desire 
for simple, flexible, low-level protocols that can be econom¬ 
ically implemented on small hosts, while not compromising 
the performance of large hosts. Supporting a variety of hosts 
also leads to a difficult software production and maintenance 
problem that can be ameliorated somewhat by having a 
protocol that is simple to implement for each new kind of 
host. Although quite a variety of hosts has been attached 
to long-haul networks such as the ARPANET, the problem 
of software development has not been too severe, since each 
individual host in such environments usually has .a software 
maintenance and development staff. In the local area network 
context where a variety of computers are all maintained by 
a small programming staff, the arguments for simplicity in 
protocol design are far stronger in our view. 

In a long-haul network, complexity results from strategies 
that attempt to make as much of the costly network band¬ 
width as possible available for transport of high-level data. 
The costs of a local area network are concentrated instead 
in the host interfaces, the hosts themselves, and their soft¬ 
ware. Two factors lead to the simplicity of low-level local 
area network protocols. 

a) Unrestricted use of overhead bits: Bandwidth is in¬ 
expensive in a local area network; there is little motivation 
to be concerned with protocol features designed to reduce 
the size of the header or overhead bits sent with each message. 
This is in contrast to protocols developed for networks making 
the more conventional assumption that bandwidth is expen- 
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sive. For example, the ARPANET NCP host-to-host protocol 
[26] initiates a connection using a 56-bit (net, host, socket) 
identifier for the'uestination, but then goes through a nego¬ 
tiation so that instead of sending this 56-bit value on sub¬ 
sequent messages, a 32-bit (net, host, link) value can be sent 
instead. It is not clear whether this conservation of bits is 
appropriate even in a long-haul network; in a local area net¬ 
work, where bandwidth is inexpensive, it is clearly irrelevant. 
Other examples of ways in which extra header space can be 
used to simplify processing include: 

1) having a single standard header format with fields in 
fixed locations, rather than having optional fields or 
multiple packet types; field extraction at the host can 
be optimized, reducing processing time; 

2) using addresses that directly translate into addresses of 
queues, buffers, ports, or processes at the receiver with¬ 
out table lookup. 

b) Simplified flow control, etc.: The low transmission 
delay inherent in local area networks, as well as their high 
data rate, can eliminate the need for complex buffer manage¬ 
ment, flow control, and network congestion control mecha¬ 
nisms. Consider, for example, flow control: the problem of 
assuring that messages arrive at the recipient at the rate it 
can handle, neither too fast, so that its buffers overflow, nor 
too slow, so that it must wait for the next message after 
processing the previous one. In a long-haul network, a re¬ 
ceiver typically allocates to the transmitter enough buffer 
space for several messages following the one currently pro¬ 
cessed by the receiver, so that messages can be placed in 
transit well before the receiver is ready to process them. 
Considerable mechanism is required to keep the sender and 
the receiver properly synchronized under these circumstances. 
In a local area network, the delay will typically be low enough 
for a much simpler flow control mechanism to be employed. 
For example, one can use the very simple strategy of not 
sending a message until the recipient has explicitly indicated, 
by a message in the other direction, that it is ready for it. 
In contrast, a network using communication satellites has 
such a high transmission delay that very complex predictive 
flow control algorithms must be used to obtain reasonable 
data throughput. 

It is crucial to understand that other factors may obviate 
these simplifications. While the data rate and delay char¬ 
acteristics of a local area network can render it essentially 
instantaneous, its speed cannot eliminate the intrinsic dis¬ 
parity that may exist between the capabilities of two hosts 
that wish to communicate with each other. These disparities 
may not show up when the two hosts are communicating 
through a long-haul network whose characteristics are so 
constraining that the principal problem is dealing with the 
restrictions of the network. While protocols for local area 
networks need not include mechanisms designed to cope 
with the limitations of the network itself, it is still necessary 
to design protocols with sufficient generality to cope with 
disparities between the capabilities of machines wishing to 
communicate through the network. Such disparities include: 

1) mismatch between the rate at which hosts can generate 
and absorb data; 

2) host delay between the time a packet is received and the 
time it is successfully processed and acknowledged: 

3) amount of buffer space available at the sender and the 
receiver. 
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Fig. 9. The urgent pointer mechanism. By transmitting a new | a 
value of the urgent pointer, a pointer into the data stream, a scndr' 
can indicate the data bufferred in the sender, network, and rec-' " 
are holding up data that must be processed quickly. The recoiuuti'- 
then adjust his use of the data stream flow control to process Itw 
bufferred data until the urgent data is processed. The shaded area , r .' 
dicates the location of potentially urgent data specified by a particuh- 
urgent pointer value. 

Further, considerable effort may be required to modify bus: 
software to provide a suitable interface to the network. I: 
one were to consider the simple flow control mechanism 
mentioned earlier, where a message is sent in the reverse 
direction requesting transmission of each message as u n 
needed, one would discover that in many cases the scheme 
was unworkable, not because the network introduced ini! : 
erable delays, but because the hosts communicating v. i;:• 
each other themselves introduced excessive delay. In a 1 a:y 
host with a time-shared operating system, for example. ik.- 
real time that elapses from the time a message is rendu-.: 
one or more processes are scheduled in response to this mo 
sage, and that process runs, to the time a message is sen! -.r 
response, could well run into a large number of millisecond! 
milliseconds during which the other host is forced to wail. 

c) Example of protocol simplification: The low-loo 
protocol initially proposed for the Laboratory for Computer 
Science Network at MIT is an example of the sort of protocol 
that results when simplicity of mechanism is a primary dcsiy.' 
goal. The Data Stream Protocol (DSP) was based on ike 
Transmission Control Protocol (TCP) used in internetwork!." 
experiments sponsored by the Defense Advanced Rcscar, ‘ 
Projects Agency [27], but evolved from original TCP due 1 2 
the continuing desire to simplify the protocol features, packer 
formats, and implementation strategies. Most of these simr !: 
fications have subsequently been incorporated into the T( 1’ 
One specific example is the mechanism used to signal f,ir¬ 
rupts and other urgent messages that are logically part o! ik-" 
sequence of data in a virtual circuit. The basic model is th J - 
the sender occasionally wants to signal the receiver that i- 
data in the stream preceding the signal (buffered somewhr- 1 
in the network) must be scanned immediately in order >■ 
respond promptly to some other important signal. A nu’cha 
nism is provided whereby a pointer into the data stream 3 
maintained at the receiver, which can be moved, when 
sender chooses, to point to a more recently transnutt f - 
piece of data. This pointer, called the urgent pointer. >•■*' 
be used to indicate the point in the data stream beyond wN»- 
there is no more urgent data. (See Fig. 9.) The urgent point'- 
can be implemented in two ways, depending upon the natur* 
of the host receiving the message. In the case of a sin ’r 
(e.g., microprocessor) host dedicated to a task that P roC( - ^ 
the incoming stream as it arrives, the host need not P r0 ^ ( 
the urgent pointer, since by design, all data, urgent 
are processed as quickly as possible. In contrast, ° n a . 
time-shared host, data need not be processed until el j 
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the process to receive the data is scheduled and requests 
u t, or b) the urgent pointer points to data not already 
fjlceived by the process. In case b) an interrupt is sent to 
’ f receiving process, indicating that data should be read 
^ processed until the urgent pointer is past. The corre- 
|Ending mechanism in TCP required that a host be capable 
*■ un derstanding and responding to a special interrupt signal 
. ;he data stream, even if the signal had no meaning to the 
ojt in its particular application of TCP. The urgent pointer, 
„ n is a simple mechanism that meets the needs of sophisti- 
j;e d host implementations without placing an excessive 
.rden on unsophisticated hosts. 

■j Special Capabilities: The other aspect of low-level 
-jtocols for local area networks to be discussed is the manner 

* • which protocols must be structured to take advantage of, 

■ j provide to higher levels, the unique capabilities of local 
iworks. Conventional low-level protocols have provided 
function best characterized as a bidirectional stream of 

. :i between two communicating entities—a virtual circuit. 
- ; e virtual circuit is implemented by a process that provides 
:”uenced delivery of packets at the destination. While a 
•iual circuit is one important form of communication, two 
iers easily provided by a local network are very useful in 
variety of contexts. These are message exchange communi- 
r.ion, where the packets exchanged are not viewed as being 
umbers of a sequence of packets but are rather isolated 
g,changes, and broadcast communication in which messages 
sent not to one particular recipient but to a selected sub- 
of the potential recipients on the network. 

a) Message exchange: A typical example of a message 
uhange is the situation in which one message asks a question 

another provides the answer. For example, if there are 
large number of services provided by nodes connected to 
local net, it is disadvantageous to maintain, on every node, 
[able giving all of the addresses of these, for whenever a 
nnge is made in the network address of any service, every 
■ie’s table will need to be revised. Rather, it may be ad- 
raageous to maintain, as a network service, a facility which 
'll take the name of a desired entity and give back its net¬ 
work address. Clearly, the pattern of communication with 

• Li service is not one of opening a connection and exchang- 
jqa large number of messages, but instead is a simple two- 
,'-usage exchange, with a query of the form “What is the 
'chess of such and such a service?” and a reply of similarly 
j^ple form. While a virtual circuit could be used for this 

"change, it is unnepded and. uses.excessive resources. ■ 

b) Broadcast: The example given above demonstrates 
:: need for a broadcast mechanism. If the service described 
•■we is intended to provide the address of network services, 
''•» can we find the address of this service itself? An obvious 
'•■utiori is to broadcast the request for information. The 
• ;: ry then takes the form “Would anyone who knows the 
^ress of such and such a network service please send it to 

There are many other examples, some apparently trivial 
nonetheless very useful, for support of broadcast queries 
5 5 local network. A microprocessor with no calendar clock 
^ broadcast a request for the time of day. A new host 
Inched to the network for the first time may broadcast a 
j^sage announcing its presence, so that those who maintain 
l, l e s may discover its existence and record the fact. Broad- 
^ niechanisms in the low-level protocols can also be quite 
in implementing higher level protocols for such appli- 
* lo ns as document distribution to multiple host nodes, and 
Speech and video conference calls. 


i 
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Why are these alternative models of communication not 
commonly found in traditional networks? The first, and 
perhaps most important reason is that long-haul networks 
have not been extensively exploited for applications in which 
computers directly query other computers with individual, 
self-contained queries. Instead, the major use of long-haul 
networks has been for long-term, human-initiated interactions 
with computers, such as direct terminal use of a remote 
computer, or long-term attachments of remote job entry 
stations. Such human interactions usually involve many 
message exchanges between sender and receiver, so that the 
extra delay and cost of initial setup of a virtual circuit is 
insignificant—perhaps even recovered by reducing redundant 
information in each message. As new applications such as 
distributed data base systems become more important, these 
alternative models will become important in long-haul net¬ 
works, but long-lived connections between terminals and 
host computers continue to dominate the usage. 

The second reason is precisely that discussed in the previous 
section concerning the relative simplicity of protocols for 
local area networks—a variety of functions performed in con¬ 
ventional networks are very difficult to understand except in 
the context of a sequence of ordered messages (a virtual 
circuit) exchanged between two nodes. For example, flow 
control is normally handled in network protocols by placing 
an upper bound on the number of messages which may be 
flowing at any one time between the sender and the receiver. 
This concept has meaning only in the restricted case where 
the sender and the receiver are a well-identified pair exchang¬ 
ing a sequence of messages. There is no obvious equivalent 
of flow control that can be applied to situations where sender 
and receiver communicate by sending arbitrary unsequenced 
messages, or where a sender broadcasts to several receivers. 
Similarly, if efficiency requires use of the shorthand version 
of an address for communication between the sender and 
the receiver, this clearly implies that the sender and the 
receiver have • negotiated this address, and agree to use it 
over some sequence of messages. Again, this idea makes no 
sense if communication is isolated in unsequenced messages. 

Another problem that is traditionally handled in the con¬ 
text of a sequence of messages is the acknowledgment to the 
sender that the receiver has correctly received a message. If 
messages are sequenced, acknowledgment can be very easily 
done by acknowledging the highest member of the sequence 
that has been successfully received. If messages bear no 
relationship to each other, then each must be identified 
uniquely by the sender, and acknowledged uniquely by the 
receiver. This increases the complexity and overhead of 
acknowledgment. However, in most cases where message 
exchange communication is the appropriate underlying com¬ 
munication model, no acknowledgment mechanism is required 
of the low-level protocol at all. For example, if a micropro¬ 
cessor system asks the time of day, it is not at all necessary 
to acknowledge that the query has been successfully received; 
the receipt of the correct time is sufficient acknowledgment. 
Similarly, a request for a network address is acknowledged by 
a return message that contains the desired address. Depend¬ 
ing on a low-level acknowledgment message to handle all 
failures can be dangerous, for it may lead to the practice 
of assuming that acknowledgment of receipt of a message 
implies that the message was processed at a high level. 

In the broadcast context, it is difficult to formulate a use¬ 
ful definition of acknowledgment that can .be supported by 
a low-level protocol. What does it mean to say that a broad- 
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cast message has been successfully received? By one of the 
possible recipients? By all of the possible recipients? One 
appropriate strategy is to rely on the high-level application 
to deal with these problems as a part of its normal operation, 
rather than have the low-level protocol concern itself with 
issues of flow control or acknowledgment at all. 

3) Protocol Structure: Based on the previous observations, 
a two-layer structure is a very natural one for low-level pro¬ 
tocols in a local area network. The bottom layer should 
provide the basic function of delivering an addressed message 
to its (one or many) destinations. This level corresponds 
to the concept of a datagram network [28]. It should also 
take on the responsibility of detecting that a message has 
been damaged in transit. To this end it may append a 
checksum to a message and verify the checksum on receipt. 
.However, this layer probably should not take on the-respon¬ 
sibility of ensuring that messages are delivered, and delivered 
in the order sent, since different applications have different 
needs and requirements for these functions. The first layer 
might be implemented entirely in hardware; however, if the 
packet size, addressing structure, or routing topology of the 
hardware is not sufficient to provide adequate message size, 
process addressing, or broadcast selectivity, some software 
help will be needed to make up the difference. 

Above this first layer should be made available a variety 
of protocols. One protocol should support a virtual circuit 
mechanism, since a virtual circuit is definitely the appropriate 
model for a great deal of the communication that will go on 
in any network, local or otherwise. As alternatives to the 
virtual circuit protocol, there should be mechanisms for 
sending isolated messages, for message exchange communi¬ 
cation, and additional alternatives to provide support for 
message models other than the ones we have discussed here. 
For example, transmission of digitized speech requires a 
communication model with some but not all of the attributes 
of the virtual circuit; in particular, reliability is of less con¬ 
cern than timeliness of arrival. 

B. Applications of Local Area Networks; Higher Level 
Protocols 

In the previous section we considered low-level protocols 
for a local area network. These protocols exist, of course, 
to support higher level protocols, which, in turn, support user 
applications. In this section we will consider a number of 
applications for which local area networks are suited. 

lj Access to Common Resources: The model of computing 
most common over the last few years is that of a large cen¬ 
tralized computer, with the only remote components being 
terminals and, perhaps, a few other I/O devices. Line control 
protocols such as SDLC [19] were created to serve this sort of 
arrangement. A simple but very important application of a 
local area network is to generalize this picture very slightly 
to include more than one central computer. As the total 
workload grows to exceed the capacity of a single machine, 
a common solution is to procure a second machine, and to 
divide the applications and workload between the two. The 
communication problem to be solved in this arrangement is 
simple but critical—to allow an individual terminal to have 
access to both of the central machines. A local area network 
can solve this problem, and provide some additional capa¬ 
bilities as well. For example, if the central facility has special¬ 
ized I/O devices such as plotters or microfilm writers, they 
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can be placed on the local area network and made accessible 
to both central machines-an advantage if a device is expensiw 
and is not heavily enough loaded to justify having one f 0 . 
each computer. Further, I/O devices can be placed remo: t 
from the central site but convenient to users; for example 
a line printer can be placed near a cluster of users. 

This pattern of sharing among several computers can '-e 
expanded to include more than just I/O devices. In f 2 -- 
the network can be used to move computations from 0j -, 
machine to another in order to spread the computin'; l 0 a' 
equally. The high speeds available in the local area network 
make this sort of load leveling much more practical than , 1 - 
the bandwidths traditionally available on long-haul network 

2} Decentralized Computing: A wide variety of new uw 
for a local area network arises if the computing power avail 
able is not strongly centralized. .Let us consider the alternative 
of a computing environment consisting of a large number n! 
relatively small machines, each dedicated to a small mimhe.- 
of users or a small number of tasks. In the extreme, we ca.-. 
look to the future and imagine the day when each user hai 
a computer on his desk instead of a terminal. Such a com 
pletely distributed computing environment by no mca.-.i 
eliminates the need for an interconnecting network, in; 
users will still need to exchange information. Data liln 
containing the results of one person’s computation will nrr: 
to be shipped through the local area network to be uscii a> 
input to other tasks. Users will wish to communicate wu- 
each other by exchanging computer mail, as is now ilo.-.r 
over the ARPANET [29], Users will still want access t> 
specialized resources which cannot be provided to each uv; 
resources such as large archival storage systems, spcciaii/rc 
output devices such as photo typesetters, or connectin', 
points to long-haul networks. All of these features can !■< 
made available through the local area network. 

31 Protocol and Operating System Support: The appluj 
tions outlined in the previous paragraph can be suppor'.rf 
by high-level protocols very similar to the ones alreadv 
existence in the ARPANET: TELNET for logging into i 
remote system through the network, and File Transfer F;.' 
tocol for exchanging data between machines [26]. When >■ 
examines how these protocols might be modified to u 11 
advantage of the special attributes of a local area net* 1 ’- 1 
for example, its higher speed, one discovers that the proWf- 
is not one of modifying the protocols, but of modifying 
operating system of the hosts connected to the network *- 
that the services available through the network appear to ■- 
a natural part of the programming environment of the 
ating system. The File Transfer Protocol in the ARP-k- s 
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command which he may invoke to move a file t rom 
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machine to another. As part of this invocation he nia> ^ 
required to identify himself at the other machine, an 
explicit file names in the syntax of the local and the o 
machine, describing exactly what action he wishes to per 
This particular view of file transfer has two disadvanta 
First, there is a lot of overhead associated with moving 
Much of the delay in moving the file seen by the 
nothing to do with the time required to send the 
through the network, but is rather the time spent esta ^ 
the connection, identifying the user at the other 
Second, the file system on the local computer un e 
nothing about the existence of files accessible ^ roU syJ<c a 
network. No matter how sophisticated the local i e 
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^ terms of keeping track of the various files that the user 
es about, it requires explicit user intervention in order to 
through the network and retrieve a file from another 
jchine- The use of a high-speed local area network will 
^ eliminate any of these problems, but will instead make 
nil more obvious to the user the overhead that the protocol 
eposes on the transfer of data. Clearly, what is needed is 
further integration of the local area network into the file 
ll!e m and user authentication mechanism of the individual 
.^rating systems, so that interchange of information between 
various machines can be done with less direct user inter- 
, nt jon. Some attempts have been made to do this within 
. f context of the ARPANET. RSEXEC is an example of a 
-otocol which makes files on various TENEX operating 
’ ■,stems in the ARPANET appear to the user to exist on a 
jgle machine [30]. 

fhe design of operating system structures to take full 
^vantage of the capabilities of local area networks repre¬ 
cats the current edge of research in this area. Examples of 
aerating systems that incorporate a high-speed local area 
-[work into their architecture are the Distributed Computing 
..stem [31], the Distributed Loop Operating System [11], 
ri MININET [32], 


VI. 


Interconnection of Local Area Networks 

WITH OTHER NETWORKS 
^ 1 Motivation for Interconnection 

want access to As was mentioned earlier, a local area network will be only 

ed to eachuw, part of the overall communication system used by the hosts 

ems, specialized -uched to it. A very important use of the local area network 
or connectioa be to provide an interconnection between hosts attached 
features can b« : a local area network and other networks such as long-haul 
i;ket-switched networks and point-to-point transmission 
As. The advantage of this method of interconnection is 
triced cost, by taking advantage of the fact that connection 
' i host to a local area network is relatively inexpensive, 
■stead of connecting all machines directly to the long-haul 
-work, one can connect all the host computers to the local 
m network, with one machine, the gateway, connected to 
nh the local area network and the long-haul network. 
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! Protocol Compatibility 

There are two pitfalls that should be avoided when plan- 
■"'8 for the interconnection of a local area network with a 
;t >g-haul network. On the-one hand, long-haul networks 
•nently cannot provide all of the functions that local area 
I'flworks can. If a local area network is initially designed to 
|' 0 'e only the function of connecting hosts to a long-haul 
Mwork, the protocols of the local network may be designed 
ier ve only the needs of communicating with the long-haul 

J ^work, and may not support the other functions that make 
Eocai area network especially attractive. On the other hand, 
' 1 local network is initially designed with no thought given 
vo uiaau'-r-,- .'' foe possibility that it may be interconnected with another 
ith movingjy^ ^ork, the protocols designed for it may lack the necessary 
by the ustfjg ^'rality. For example, the addressing structure used on 
nd the datajgT local area network may not be able to express destinations 
spent ^e the local network. In either case, the only after-the- 

i other sitglSr solution is to implement a second set of protocols for 
mter unde $S k local area network, s that different protocols are used 
iible thiot^^ ^ intercommunication w j^h long-haul networks and for 
: local fik. ggg; ^ services. This proliferation of protocols is undesirable, 
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as it adds to the cost of software development associated 
with each new host added to the local area network. To 
avoid these pitfalls, it is important that all the functions a 
local area network is to provide must be considered from 
the very inception of the design of the network, and the 
protocols for the network must be designed to support that 
entire range of functionality. 

Fortunately, initial experiments with protocols for local 
area networks suggest that a uniform approach to protocol 
design can support both specialized local network functions 
and interconnection with other networks, provided that both 
functions are envisioned from the start. Although the pro¬ 
tocols used in the local area network must be made slightly 
more general to handle the internetworking situation, there 
is no interference with the realization of the purely local 
network functions. For example, a more general address 
field must be used to specify the destination of a message, 
but the only overhead implied if this same addressing struc¬ 
ture is used for purely local messages is additional bits in 
the message to hold a presumably larger address. Since band¬ 
width is inexpensive, the bits “wasted” on this larger address 
are presumably irrelevant. 

A slightly more difficult problem, one that is still being 
studied, is the problem of speed matching between the local 
area network and the long-haul network. As this paper has 
characterized the difference between local nets and long-haul 
nets, it is reasonable to presume that the local network will 
have a much higher data rate. If a host sends a large number 
of packets into the local area network with an ultimate des¬ 
tination to be reached through the long-haul network, the 
packets may arrive at the gateway much faster then the 
gateway can pass them to the long-haul network. Some 
mechanism will be required to prevent the gateway from 
exhausting its buffer space. The speed matching problem 
is not unique to the gateway between the local area network 
and the long-haul network; it occurs any time two networks 
of differing speed are connected together. (The problem may 
be more extreme here, though, due to the greater speed dif¬ 
ference that can be encountered between local area and some 
long-haul networks. Satellite networks with speeds com¬ 
patible to local networks are quite conceivable, yet are a 
long-haul technology.) A general discussion of the problems 
of internetworking, and some proposed solutions can be 
found in a companion paper by Cerf and Kirstein in this 
issue [33]. 

At the- next higher level of protocol, one finds facilities that 
support various communications models, such as virtual 
circuits, broadcast, and message exchange. In interconnecting 
to a long-haul network we are chiefly forced to deal with a 
virtual circuit model, since that is the only pattern of com¬ 
munication usually supported by commercial long-haul 
networks. Here, it is appropriate to use a virtual circuit pro¬ 
tocol in the local area network as similar as possible to that 
used in the long-haul network, so that translation between 
the two is easy. Although there is not as much practical 
experience available in the area of network interconnection 
as could be desired, it appears that one can develop a virtual 
circuit protocol for a local area network that is a compatible 
subset (in the sense of using compatible packet formats and 
control algorithms) of a suitable long-haul virtual circuit 
protocol. This means that it is not necessary to implement 
two complete virtual circuit protocols, one for internal local 
network use and the other for communication out through 
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the local net. It leaves unanswered the question of how the 
additional features, such as complex flow control, buffering, 
and speed matching required for the long-haul protocol should 
be implemented. One approach would be to implement them 
in every host that desires to communicate over the long-haul 
network; this implies a programming burden for every ma¬ 
chine. An alternative would be to implement the additional 
functions in the gateway machine that interconnects the local 
area network to the long-haul network. This would add 
considerable complexity to the gateway, for it will have to 
cope with such problems as the speed differential between 
the two networks without having the benefit of the flow 
control mechanisms normally used for this purpose in the 
long-haul network. At this time, it is not clear whether the 
gateway can assume the entire responsibility for augmenting 
■a local netw.ork virtual circuit protocol with, the- functions 
required for communication through a long-haul network. 

It would be advantageous to make sure the local area net¬ 
work protocols are also compatible with other communica¬ 
tion models, such as single message exchange or selective 
broadcast, that may become available on commercial long-haul 
networks in the future. However, this presupposes that the 
long-haul networks attached to the local area network use 
a two-layer low-level protocol implementation such as that 
described for the local area network, and if the long-haul 
networks do use such an implementation, that they provide 
an interface that allows direct use of the datagram layer. 
Many current long-haul networks do not provide that interface. 

VII. The Subnetwork Concept 

Resting midway between the monolithic, single-technology, 
local area network and the internetworking environment is an 
approach to local area networking that we term the subnet¬ 
work concept, which provides for a mix of network technol¬ 
ogies within a uniform addressing and administrative structure. 

A. Gen era l A pproach 

A local area network can be composed of a collection of 
subnetworks, possibly implemented with various network 
technologies and perhaps with various transmission rates, but 
using identical software protocols, compatible packet sizes, 
and a single overall homogeneous address space. 5 These 
subnetworks are interconnected by bridges, which are midway 
in complexity between the repeaters used in a multisegment 
contention bus network (ETHERNET) and the gateway pro¬ 
cessor used between networks in an internetworking environ¬ 
ment. This general structure is indicated in Fig. 10. A bridge 
links two subnetworks, generally at a location at which they 
are physically adjacent, and selectively repeats packets from 
each of them to the other, according to a “filter function.” 6 
In addition, since they buffer the packets they repeat, they 
can perform a speed-matching function as well. 

B. Advantages of Subnetworking 

The subnetworking concept enables a variety of technologies 
and data rates to be utilized in a single local area network, 
each to its best advantage. For example, a network could 


’The subnetwork concept, as we describe it, is a generalization of 
an approach suggested by Pierce [5] for use with multiple loops or 
rings. 

’The concept of the filter function is introduced in the “filtering 
repeaters” described by Boggs and Metcalfe [14]. 



Fig. 10. The subnetwork concept. Here, a local area network is c ,, m 
posed of a number of subnetworks, linked in some fashion o>- briiim 
The subnetworks, though of differing technologies, share one addin, 
space, and the same protocols are used over the entire network; 
the bridges can be simpler than the gateway which connects she i,'„J 
area network to the long-haul network. Viewed externally, from 
side the dashed line in the figure, the local area network appears {<> 
monolithic. 

be constructed with a contention bus subnetwork, perluri 
using coaxial cable originally installed for CATV, and with r 
ring subnetwork, using twisted pair which can be easily i- 
stalled in a crowded laboratory environment. These iwtmuS 
networks could be of different data rates; the bridge betwee- 
the two will handle the speed difference between them. 

Subnetworking also provides an orderly means for handh.-.j 
growth in traffic. Local area networks perform best, prowdi.-i 
high throughput with low delay, when they are not hcjv.:. 
loaded. As traffic on a local area network grows with t:mr 
if a higher speed technology is not available, it may be do¬ 
able to split the network into two or more interconno-i.-d 
subnetworks. Since the bridges which interconnect t-* 
subnetworks are selective in their repeating of packels "ach-u 
the bridge,” not all packets from a subnetwork will fU"» 
all other subnetworks, and the traffic density on each >uN 
network will be less than that of the original monolithic nu 
work. If the partitioning of the hosts into subnetworks -a*, 
be done along the lines of “communities of interest.” 
that a group of hosts with high traffic rates among tlicnisr.’ 
but with substantially lower traffic rates to other host' i/: 
placed in the same subnetwork, traffic across the bridges ■*- 
be minimized, and a greater fraction of all packets will ' :il 
within their subnetwork of origin. 

C. Bridges 

A bridge, depicted in Fig. 11, contains: 

two network interfaces, one appropriate to each o! the ■* 
subnetworks it interconnects, 

a limited amount of packet buffer memory, and _ _ 

a control element, which implements an appropriate •• 
function to decide which messages to “pull olf °nc 
network and buffer until it has an opportunity t° - ct - 
mit it to the other subnetwork. 

The topology of the subnetworks interconnected b> a 
determines the complexity of its filter function. •• 
with a simple filter function can be implemented using 
state machine as its control element; a complex filter ^ 
which may involve a periodic exchange of information ^ 
bridges on the network to determine correct routing- 
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require the capabilities of a microprocessor [34]. 

A bridge must buffer packets since, upon receiving 
from one subnetwork which it decides to repeat to 
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ll. The structure of a bridge. A bridge would most naturally be 
icaied at a point where the two subnetworks it interconnects have 
made physically adjacent. 


^network, it must wait for an opportunity to transmit on 
•jl subnetwork, according to the control structure of that 
network. Packet buffers also aid a bridge in handling 
-;;intaneous cross-bridge traffic peaks during which the 
-iiTic offered by one subnetwork exceeds the available 
-jacity of the other. This situation can arise if the bridge 
•:;rconnects subnetworks of dissimilar data transmission 
01 subnetworks of drastically different traffic densities, 
owever, if the sustained cross-bridge traffic offered is greater 
:in the target subnetwork can handle, the bridge must 
<ard packets. This is an acceptable course of action, as 
,al area network protocols are generally prepared to handle 
si packets. 

,. Transparency 

i The subnetwork structure of a local area network should be 
osparent, both to the hosts on the local area network and 
ihe "outside world”—other networks to which the local 
::i network may be connected via gateways. A host on the 
d area network wishing to transmit a packet to another 
- -J have no knowledge of whether that host is on the same 
.'network, in which case the packet will be received by the 
filiation host directly, or whether the destination host is 
: mother subnetwork, in which case the packet is retrai¬ 
ned by one or more bridges. In particular, no ordinary 
•U packets are ever addressed to a bridge; rather, packets 
simply addressed to their destination hosts, and may be 
i ded up by a bridge and passed along through other sub- 
•'•"»orks, finally reaching their destinations. This is a key 
-t-sinction between subnetworking, with bridges, and inter- 
• : '*orkmg, with gateways; in internetworking, a host about 
i nansmit a packet must realize that the host to which it is 
, -Lessed is on a different network. The sending host must 
nsmit the message in a local network “wrapper” to an 
hopriate gateway, which -“unwraps” it, performs protocol 
Versions, if any, packet fragmentation, etc., as necessary, 
lhen transmits the message into the other network. In 
Networking, protocols are identical over all subnetworks, 
Packet sizes are compatible, so that neither protocol con- 
lo n nor fragmentation takes place in the bridges. Finally, 
,,J s mentioned above, a packet is directly addressed to its 
Nation host, not to a bridge, for hosts do not know that 
'ocal area network is composed of subnetworks. 

Im Pact on Network Characteristics 

flitting a local area network into subnetworks has little 
ic t on the key characteristics of the network. From the 
of view of the users and hosts of the network, address- 
a affected only slightly, if at all. Bridges must determine 
or not a packet should be picked up for retransmis- 
One way to aid bridges in this determination is to include 
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a subnetwork field in the address of each host. Other routing 
techniques which have no impact at all on addressing (such as 
complete table look-up of host addresses by the bridges) can 
be implemented, although usually at the expense of greater 
complexity within the bridges. 

Splitting a local area network into subnetworks should have 
no effect on the protocols of the network. One exception 
is if a particular subnetwork technology provides a hardware 
acknowledgment of delivery of a packet (as in the DCS Ring 
Network) [2]; this acknowledgment may only indicate suc¬ 
cessful receipt by a bridge. However, not all network tech¬ 
nologies provide hardware acknowledgments, and, in a net¬ 
work of mixed technologies, host-to-host acknowledgments 
will generally be provided by software protocols. Traffic is, 
of course, affected by subnetworking in a positive way. 
Splitting a local area network into subnetworks in a judicious 
way can minimize the overall traffic of the network; bottle¬ 
necks can be eliminated by using higher bandwidth tech¬ 
nologies for affected subnetworks. 

F. The Long-Distance Bridge 

There are situations in which it is necessary to interconnect 
two subnetworks of a local area network which cannot be 
brought physically adjacent to one another so that an ordinary 
bridge may be connected between them. An example of 
this would be a local area network on a university campus, 
with a major research laboratory across town. The laboratory 
may be beyond the range of a twisted-pair ring network or 
a coaxial cable contention bus network; or it may be within 
range, but it may be impossible for the university to install 
its own cables between them. 7 The off campus research lab¬ 
oratory can be given its own subnetwork, connected to the 
main campus subnetwork via a specialized long-distance 
bridge. 

A long-distance bridge is made up of two half-bridges at 
either end of a suitable full-duplex point-to-point communi¬ 
cation link, such as a high-bandwidth common carrier circuit, 
an optical link, or a private microwave link (Fig. 12). Some 
other network technology such as packet radio could be used 
to derive this point-to-point link as desired. 8 Each half-bridge 
contains an appropriate interface to its subnetwork, packet 
buffers, and a controller. In addition to its filtering function, 
the controller of a half-bridge regulates the flow of data over 
the communication link between the two halves of the bridge. 
Of course, it is possible' that the bridge communication link 
may be of lower bandwidth than the two subnetworks' it 
interconnects. Additional packet buffers at each half-bridge 
can help to smoothe out traffic peaks, but if the communi¬ 
cation link is a bottleneck, the long-distance bridge must 
discard packets just as an ordinary bridge does when it is 
overloaded. 9 

1 Although common carriers such as the Bell System operating com¬ 
panies are moving in the direction of leasing wire pairs for transmission 
of digital signals with customer-provided equipment, these circuits are 
not intended for use at the high bandwidth of local area networks, 
and are generally routed through central offices rather than point-to- 
point. 

8 Although we do not discuss it further in this paper, there is an 
interesting philosophical issue whether the intervening network should 
be viewed in the internetworking context using gateways or as a point- 
to-point link within a single bridge. 

9 if the bottleneck created by the communication link of a long 
bridge is severe, the local area network advantages of high-bandwidth 
communication with low delay will be forfeited. 
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Fig. 12. The “long bridge.” In this case, the two subnetworks cannot 
be made physically adjacent, so a half-bridge is attached to each, and 
a full-duplex communication link is employed to interconnect the 
two half-bridges. The control and filter functions, and the packet 
buffers, are replicared in each half-bridge. 


VIII. Conclusion 

The utilization of a technological innovation often occurs 
in two stages. In the first stage, the innovation is exploited 
to perform better the same tasks that were already being 
performed. In the second stage, new applications are dis¬ 
covered, which could not be reasonably performed or even 
forseen prior to the innovation. Local area networks are now 
on the threshold o: this second stage. While there is still much 
room for creativity in improving the innovation itself—reducing 
the cost of the nerwork interface and increasing its speed and 
convenience-the real challenge lies in identifying new sorts 
of applications that a local area network can make possible. 

Current trends in hardware costs encourage abandoment of 
a single large computer in favor of a number of smaller ma¬ 
chines. This decentralization of computing power is, for 
many applications, a natural and obvious pattern. In many 
information processing applications, for example, the infor¬ 
mation itself is distributed in nature, and can most appro¬ 
priately be managed by distributed machines. Distributed 
applications can only be constructed, however, if it is possible 
to link their machines together in an effective manner. Subject 
to their geographical limitations, local area networks offer 
a very effective and inexpensive way to provide this inter¬ 
connection. The greatest impact of local area networks will 
come with the development of operating systems that inte¬ 
grate the idea of distribution and communication at a fun¬ 
damental level. 

The impact of local area networks on the decentralization 
of computing is sociological as well as technological. Oper¬ 
ational control of centralized computers has traditionally 
been vested in the staff of a computer center. The trend 
toward decentralized computing greatly increases the au¬ 
tonomy. of individual managers in the operation of their 
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staff of computer managers. The communication capjy- 
made available by local area networks will serve to bind T* 
decentralized machines together into a unified inforrnii 
processing resource. The effectiveness of this resource • ' 

be measured by the degree of coherence it achieves. ..h*. 
in turn, depends upon the care and foresight put i n t q 
design of the local area network and the development / '■ 
standards for communication at all levels. It is in the .de--. 
fication of areas in which standards are needed, and in iLf- 
development, that the staff of the “computer center" ,,t 
future will find its work. 
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I. Introduction 
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to other users? The answer to this question is funda¬ 
mental in defining the appearance of the network to its 
For example, does one user have to know exactly where 
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the other is located, or just the region of the network, or is the 
address independent of location? Can he identify himself to 
the network or does the network know who he is automati¬ 
cally? If self-identification is possible, can he have several 
addresses corresponding to several roles or functions? Can he 
have multiple connections to the network, and can he move 
from one location to another without changing his address(es)? 
Can he send a single message- to a group or list of other users 
(e.g., a mailing list) automatically? Can he set up “conference 
calls” with other users, and join conferences in progress? Can 
he send a message to all other users? 

These questions are important for several reasons: some ad¬ 
dressing modes allow functions which would not be available 
otherwise (e.g., the ability to send a message to a distribution 
list without knowing the identity or location of the members 
of the list), and which are essential for certain types of users 
and applications. Furthermore, these addressing capabilities 
offer opportunities for efficient implementations that would 
not exist otherwise (e.g., a message addressed to a group can 
be transmitted with fewer packets than the equivalent sepa¬ 
rately addressed messages). The topic of addressing has re¬ 
ceived surprisingly little attention to date; the present paper 
indicates that it may be a fruitful area for further work. 
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have multiple connections to the network, and can he move 
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Can he send a single message' to a group or list of other users 
(e.g., a mailing list) automatically? Can he set up “conference 
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These questions are important for several reasons; some ad¬ 
dressing modes allow functions which would not be available 
otherwise (e.g., the ability to send a message to a distribution 
list without knowing the identity or location of the members 
of the list), and which are essential for certain types of users 
and applications. Furthermore, these addressing capabilities 
offer opportunities for efficient implementations that would 
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TOW SHOULD one user of a network address messages 
I to other users? The answer to this question is funda- 
mental in defining the appearance of the network to its 
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the other is located, or just the region of the network, or is the 
address independent of location? Can he identify himself to 
the network or does the network know who he is automati¬ 
cally? If self-identification is possible, can he have several 
addresses corresponding to several roles or functions? Can he 
have multiple connections to the network, and can he move 
from one location to another without changing his address(es)? 
Can he send a single message- to a group or list of other users 
(e.g., a mailing list) automatically? Can he set up “conference 
calls” with other users, and join conferences in progress? Can 
he send a message to all other users? 

These questions are important for several reasons: some ad¬ 
dressing modes allow functions which would not be available 
otherwise (e.g., the ability to send a message to a distribution 
list without knowing the identity or location of the members 
of the list), and which are essential for certain types of users 
and applications. Furthermore, these addressing capabilities 
offer opportunities for efficient implementations that would 
not exist otherwise (e.g., a message addressed to a group can 
be transmitted with fewer packets than the equivalent sepa¬ 
rately addressed messages). The topic of addresang has re¬ 
ceived surprisingly little attention to date; the present paper 
indicates that it may be a fruitful area for further work. 
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Communication link 



Fig. 12. The “long bridge.” In this case, the two subnetworks cannot 
be made physically adjacent, so a half-bridge is attached to each, and 
a full-duplex communication link is employed to interconnect the 
two half-bridges. The control and filter functions, and the packet 
buffers, are replicated in each half-bridge. 


VIII. Conclusion 

The utilization of a technological innovation often occurs 
in two stages. In the first stage, the innovation is exploited 
to perform better the same tasks that were already being 
performed. In the second stage, new applications are dis¬ 
covered, which could not be reasonably performed or even 
forseen prior to the innovation. Local area networks are now 
on the threshold of this second stage. While there is still much 
room for creativity in improving the innovation itself-reducing 
the cost of the network interface and increasing its speed and 
convenience—the real challenge lies in identifying new sorts 
of applications that a local area network can make possible. 

Current trends in hardware costs encourage abandoment of 
a single large computer in favor of a number of smaller ma¬ 
chines. This decentralization of computing power is, for 
many applications, a natural and obvious pattern. In many 
information processing applications, for example, the infor¬ 
mation itself is distributed in nature, and can most appro¬ 
priately be managed by distributed machines. Distributed 
applications can only be constructed, however, if it is possible 
to link their machines together in an effective manner. Subject 
to their geographical limitations, local area networks offer 
a very effective and inexpensive way to provide this inter¬ 
connection. The greatest impact of local area networks will 
come with the development of operating systems that inte¬ 
grate the idea of distribution and communication at a fun¬ 
damental level. 

The impact of local area networks on the decentralization 
of computing is sociological as well as technological. Oper¬ 
ational control of centralized computers has traditionally 
been vested in the staff of a computer center. The trend 
toward decentralized computing greatly increases the au¬ 
tonomy. of individual managers in the operation of their 
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machines, and appears to reduce the need for 


staff of computer managers. The communication 


a j 


Mpjbi:, 


made available by local area networks will serve to bind t'- 
decentralized machines together into a unified infornut i 
processing resource. The effectiveness of this resource " ' 
be measured by the degree of coherence it achieves W |. , 
in turn, depends upon the care and foresight put into .f 
design of the local area network and the development / 
standards for communication at all levels. It is in the ulc-- 
fication of areas in which standards are needed, and in tv., 
development, that the staff of the “computer center" 
future will find its work. 
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jnetwork, it must wait for an opportunity to transmit on 
•jl subnetwork, according to the control structure of that 
' inetwork. Packet buffers also aid a bridge in handling 
•cimtaneous cross-bridge traffic peaks during which the 
-iftic offered by one subnetwork exceeds the available 
jjacity of the other. This situation can arise if the bridge 
■^connects subnetworks of dissimilar data transmission 
. :; s, or subnetworks of drastically different traffic densities, 
■never, if the sustained cross-bridge traffic offered is greater 
■ in the target subnetwork can handle, the bridge must 
...ard packets. This is an acceptable course of action, as 
,al area network protocols are generally prepared to handle 
ii packets. 

Transparency 

{ [he subnetwork structure of a local area network should be 
lasparent, both to the hosts on the local area network and 
the "outside world”—other networks to which the local 
~i network may be connected via gateways. A host on the 
cal area network wishing to transmit a packet to another 
■-d have no knowledge of whether that host is on the same 
.network, in which case the packet will be received by the 
•■lination host directly, or whether the destination host is 
: another subnetwork, in which case the packet is retrans- 
:tcd by one or more bridges. In particular, no ordinary 
•:a packets are ever addressed to a bridge; rather, packets 
:■■: simply addressed to their destination hosts, and may be 
i'Ted up by a bridge and passed along through other sub- 
"■'*orks, finally reaching their destinations. This is a key 
■t-sanction between subnetworking, with bridges, and inter- 
• "vorking, with gateways: in internetworking, a host about 
j iransmit a packet must realize that the host to which it is 
j -essed is on a different network. The sending host must 
‘•ismit the message in a local network “wrapper” to an 
?iopriate gateway, which .“unwraps” it, performs protocol 
Versions, if any, packet fragmentation, etc., as necessary, 
[ ben transmits the message into the other network. In 
Networking, protocols are identical over all subnetworks, 
packet sizes are compatible, so that neither protocol con- 
ton nor fragmentation takes place in the bridges. Finally, 
VJ s mentioned above, a packet is directly addressed to its 
Nation host, not to a bridge, for hosts do not know that 
'ocal area network is composed of subnetworks. 

!m Pact on Network Characteristics 

ing a local area network into subnetworks has little 
ic t on the key characteristics of the network. From the 
°f view of the users and hosts of the network, address- 
15 affected only slightly, if at all. Bridges must determine 
<1 * ler or not a packet should be picked up for retransmis- 
°ne way to aid bridges in this determination is to include 
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a subnetwork field in the address of each host. Other routing 
techniques which have no impact at all on addressing (such as 
complete table look-up of host addresses by the bridges) can 
be implemented, although usually at the expense of greater 
complexity within the bridges. 

Splitting a local area network into subnetworks should have 
no effect on the protocols of the network. One exception 
is if a particular subnetwork technology provides a hardware 
acknowledgment of delivery of a packet (as in the DCS Ring 
Network) [2]; this acknowledgment may only indicate suc¬ 
cessful receipt by a bridge. However, not all network tech¬ 
nologies provide hardware acknowledgments, and, in a net¬ 
work of mixed technologies, host-to-host acknowledgments 
will generally be provided by software protocols. Traffic is, 
of course, affected by subnetworking in a positive way. 
Splitting a local area network into subnetworks in a judicious 
way can minimize the overall traffic of the network; bottle¬ 
necks can be eliminated by using higher bandwidth tech¬ 
nologies for affected subnetworks. 

F. The Long-Distance Bridge 

There are situations in which it is necessary to interconnect 
two subnetworks of a local area network which cannot be 
brought physically adjacent to one another so that an ordinary 
bridge may be connected between them. An example of 
this would be a local area network on a university campus, 
with a major research laboratory across town. The laboratory 
may be beyond the range of a twisted-pair ring network or 
a coaxial cable contention bus network; or it may be within 
range, but it may be impossible for the university to install 
its own cables between them. 7 The off campus research lab¬ 
oratory can be given its own subnetwork, connected to the 
main campus subnetwork via a specialized long-distance 
bridge. 

A long-distance bridge is made up of two half-bridges at 
either end of a suitable full-duplex point-to-point communi¬ 
cation link, such as a high-bandwidth common carrier circuit, 
an optical link, or a private microwave link (Fig. 12). Some 
other network technology such as packet radio could be used 
to derive this point-to-point link as desired. 8 Each half-bridge 
contains an appropriate interface to its subnetwork, packet 
buffers, and a controller. In addition to its filtering function, 
the controller of a half-bridge regulates the flow of data over 
the communication link between the two halves of the bridge. 
Of course, it is possible' that the bridge communication link 
may be of lower bandwidth than the two subnetworks' it 
interconnects. Additional packet buffers at each half-bridge 
can help to smoothe out traffic peaks, but if the communi¬ 
cation link is a bottleneck, the long-distance bridge must 
discard packets just as an ordinary bridge does when it is 
overloaded. 9 

7 Although common carriers such as the Bell System operating com¬ 
panies are moving in the direction of leasing wire pairs for transmission 
of digital signals with customer-provided equipment, these circuits are 
not intended for use at the high bandwidth of local area networks, 
and are generally routed through central offices rather than point-to- 
point. 

8 Although we do not discuss it further in this paper, there is an 
interesting philosophical issue whether the intervening network should 
be viewed in the internetworking context using gateways or as a point- 
to-point link within a single .bridge. 

9 If the bottleneck created by the communication link of a long 
bridge is severe, the local area network advantages of high-bandwidth 
communication with low delay will be forfeited. 
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the local net. It leaves unanswered the question of how the 
additional features, such as complex flow control, buffering, 
and speed matching required for the long-haul protocol should 
be implemented. One approach would be to implement them 
in every host that desires to communicate over the long-haul 
network; this implies a programming burden for every ma¬ 
chine. An alternative would be to implement the additional 
functions in the gateway machine that interconnects the local 
area network to the long-haul network. This would add 
considerable complexity to the gateway, for it will have to 
cope with such problems as the speed differential between 
the two networks without having the benefit of the flow 
control mechanisms normally used for this purpose in the 
long-haul network. At this time, it is not clear whether the 
gateway can assume the entire responsibility for augmenting 
■a local network virtual circuit protocol with, the- functions 
required for communication through a long-haul network. 

It would be advantageous to make sure the local area net¬ 
work protocols are also compatible with other communica¬ 
tion models, such as single message exchange or selective 
broadcast, that may become available on commercial long-haul 
networks in the future. However, this presupposes that the 
long-haul networks attached to the local area network use 
a two-layer low-level protocol implementation such as that 
described for the local area network, and if the long-haul 
networks do use such an implementation, that they provide 
an interface that allows direct use of the datagram layer. 
Many current long-haul networks do not provide that interface. 

VII. The Subnetwork Concept 

Resting midway between the monolithic, single-technology, 
local area network and the internetworking environment is an 
approach to local area networking that we term the subnet¬ 
work concept, which provides for a mix of network technol¬ 
ogies within a uniform addressing and administrative structure. 

A. General Approach 

A local area network can be composed of a collection of 
subnetworks, possibly implemented with various network 
technologies and perhaps with various transmission rates, but 
using identical software protocols, compatible packet sizes, 
and a single overall homogeneous address space. 5 These 
subnetworks are interconnected by bridges, which are midway 
in complexity between the repeaters used in a multisegment 
contention bus network (ETHERNET) and the gateway pro¬ 
cessor used between networks in an internetworking environ¬ 
ment. This general structure is indicated in Fig. 10. A bridge 
links two subnetworks, generally at a location at which they 
are physically adjacent, and selectively repeats packets from 
each of them to the other, according to a “filter function.” 6 
In addition, since they buffer the packets they repeat, they 
can perform a speed-matching function as well. 

B. Advantages of Sub networking 

The subnetworking concept enables a variety of technologies 
and data rates to be utilized in a single local area network, 
each to its best advantage. For example, a network could 


’The subnetwork concept, as we describe it, is a generalization of 
an approach suggested by Pierce [5] for use with multiple loops or 
rings. 

’The concept of the filter function is introduced in the “filtering 
repeaters” described by Boggs and Metcalfe [14]. 
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Fig. 10. The subnetwork concept. Here, a local area network is c „ m 
posed of a number of subnetworks, linked in some fashion by bridi„ 
The subnetworks, though of differing technologies, share one addr^, 
space, and the same protocols are used over the entire network; Thw 
the bridges can be simpler than'the gateway which connects ihe 
area network to the long-haul network. Viewed externally, from 
side the dashed line in the figure, the local area network appearsb« 
monolithic. 

be constructed with a contention bus subnetwork, perhari 
using coaxial cable originally installed for CATV, and with > 
ring subnetwork, using twisted pair which can be easily m 
stalled in a crowded laboratory environment. These two sub 
networks could be of different data rates; the bridge betwee.-. 
the two will handle the speed difference between them. 

Subnetworking also provides an orderly means for handli.-j 
growth in traffic. Local area networks perform best, provide 
high throughput with low delay, when they are not hca-.d. 
loaded. As traffic on a local area network grows wilh tin- 
if a higher speed technology is not available, it may be dn:.* 
able to split the network into two or more intcrconncctf-’ 
subnetworks. Since the bridges which interconnect it.j 
subnetworks are selective in their repeating of packets "acn-u 
the bridge,” not all packets from a subnetwork will fU"» ■ ' 
all other subnetworks, and the traffic density on each >uS 
network will be less than that of the original monolithic n.-i 
work. If the partitioning of the hosts into subnetworks .j-. 
be done along the lines of “communities of interest.” 
that a group of hosts with high traffic rates among tliem'ri'-'’ 
but with substantially lower traffic rates to other host' i:! 
placed in the same subnetwork, traffic across the bridges »- 
be minimized, and a greater fraction of all packets wdl ,:jl 
within their subnetwork of origin. 

C. Bridges 

A bridge, depicted in Fig. 11, contains: 

two network interfaces, one appropriate to each ot the •* 
subnetworks it interconnects, 
a limited amount of packet buffer memory, and 
a control element, which implements an appropriate ^ 
function to decide which messages to “pull olf °ne - 
network and buffer until it has an opportunity to ret--*— 
mit it to the other subnetwork. 

The topology of the subnetworks interconnected b> a h. 
determines the complexity of its filter function. , 

with a simple filter function can be implemented using ^ 
state machine as its control element; a complex filter 
which may involve a periodic exchange of information 
bridges on the network to determine correct routing. 
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A bridge must buffer packets since, upon receiving ^ 
from one subnetwork which it decides to repeat to 
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^ terms of keeping track of the various files that the user 
about, it requires explicit user intervention in order to 
^ through the network and retrieve a file from another 
s achin e - The use of a high-speed local area network will 
t eliminate any of these problems, but will instead make 
<in more obvious to the user the overhead that the protocol 
imposes on the transfer of data. Clearly, what is needed is 
i further integration of the local area network into the file 
llte m and user authentication mechanism of the individual 
grating systems, so that interchange of information between 
, various machines can he done with less direct user inter- 
n tion. Some attempts have been made to do this within 
{ context of the ARPANET. RSEXEC is an example of a 
utocol which makes files on various TENEX operating 
.stems in the ARPANET appear to the user to exist on a 
jgle machine [30]. 

Hie design of operating system structures to take full 
^vantage of the capabilities of local area networks repre¬ 
ss the current edge of research in this area. Examples of 
,*eiati:ig systems that incorporate a high-speed local area 
■iiwork into their architecture are the Distributed Computing 
..stem [31], the Distributed Loop Operating System [11], 
:J MININET [32], 

VI. Interconnection of Local Area Networks 
WITH OTHER NETWORKS 

'f i Motivation for Interconnection 
As was mentioned earlier, a local area network will be only 
.part of the overall communication system used by the hosts 
riached to it. A very important use of the local area network 
| in be to provide an interconnection between hosts attached 
: a local area network and other networks such as long-haul 
idcet-switched networks and point-to-point transmission 
ds. The advantage of this method of interconnection is 
-Juced cost, by taking advantage of the fact that connection 
' a host to a local area network is relatively inexpensive, 
mead of connecting all machines directly to the long-haul 
stwork, one can connect all the host computers to the local 
•a network, with one machine, the gateway, connected to 
>:th the local area network and the long-haul network. 

! Protocol Compatibility 

There are two pitfalls that should be avoided when plan¬ 
ts for the interconnection of a local area network with a 
■°g-haul network. On the one hand, long-harul networks 
Gently cannot provide all of the functions that local area 
fl'vorks can. If a local area network is initially designed to 
,<rte only the function of connecting hosts to a long-haul 
I'flwork, the protocols of the local network may be designed 
■serve only the needs of communicating with the long-haul 
Nwork, and may not support the other functions that make 
, w ., ( J-ocal area network especially attractive. On the other hand, 

ishes to ‘'ocal network is initially designed with no thought given 

vo disadvamW* ■ the possibility that it may be interconnected with another 
ith movingjy^ '* ,Wor k, the protocols designed for it may lack the necessary 
by the ■’wality. For example, the addressing structure used on 

nd the datajjlr ^ local area network may not be able to express destinations 
spent esta _*^Sj^ the local network. In either case, the only after-the- 
; other sit|^S solution is to implemen a second set of protocols for 
iuter unde $5§ 1* loca l area network, s that different protocols are used 
iible thiodj!^^ ^ intercommunication with long-haul networks and for 
; local ^ services. This proliferation of protocols is undesirable. 
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as it adds to the cost of software development associated 
with each new host added to the local area network. To 
avoid these pitfalls, it is important that all the functions a 
local area network is to provide must be considered from 
the very inception of the design of the network, and the 
protocols for the network must be designed to support that 
entire range of functionality. 

Fortunately, initial experiments with protocols for local 
area networks suggest that a uniform approach to protocol 
design can support both specialized local network functions 
and interconnection with other networks, provided that both 
functions are envisioned from the start. Although the pro¬ 
tocols used in the local area network must be made slightly 
more general to handle the internetworking situation, there 
is no interference with the realization of the purely local 
network functions. For example, a more general address 
field must be used to specify the destination of a message, 
but the only overhead implied if this same addressing struc¬ 
ture is used for purely local messages is additional bits in 
the message to hold a presumably larger address. Since band¬ 
width is inexpensive, the bits “wasted” on this larger address 
are presumably irrelevant. 

A slightly more difficult problem, one that is still being 
studied, is the problem of speed matching between the local 
area network and the long-haul network. As this paper has 
characterized the difference between local nets and long-haul 
nets, it is reasonable to presume that the local network will 
have a much higher data rate. If a host sends a large number 
of packets into the local area network with an ultimate des¬ 
tination to be reached through the long-haul network, the 
packets may arrive at the gateway much faster then the 
gateway can pass them to the long-haul network. Some 
mechanism will be required to prevent the gateway from 
exhausting its buffer space. The speed matching problem 
is not unique to the gateway between the local area network 
and the long-haul network; it occurs any time two networks 
of differing speed are connected together. (The problem may 
be more extreme here, though, due to the greater speed dif¬ 
ference that can be encountered between local area and some 
long-haul networks. Satellite networks with speeds cora- 
parible to local networks are quite conceivable, yet are a 
long-haul technology.) A general discussion of the problems 
of internetworking, and some proposed solutions can be 
found in a companion paper by Cerf and Kirstein in this 
issue [33], 

At the- next higher level of protocol, one finds facilities that 
support various communications models, such as virtual 
circuits, broadcast, and message exchange. In interconnecting 
to a long-haul network we are chiefly forced to deal with a 
virtual circuit model, since that is the only pattern of com¬ 
munication usually supported by commercial long-haul 
networks. Here, it is appropriate to use a virtual circuit pro¬ 
tocol in the local area network as similar as possible to that 
used in the long-haul network, so that translation between 
the two is easy. Although there is not as much practical 
experience available in the area of network interconnection 
as could be desired, it appears that one can develop a virtual 
circuit protocol for a local area network that is a compatible 
subset (in the sense of using compatible packet formats and 
control algorithms) of a suitable long-haul virtual circuit 
protocol. This means that it is not necessary to implement 
two complete virtual circuit protocols, one for internal local 
network use and the other for communication out through 
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cast message has been successfully received? By one of the 
possible recipients? By all of the possible recipients? One 
appropriate strategy is to rely on the high-level application 
to deal with these problems as a part of its normal operation, 
rather than have the low-level protocol concern itself with 
issues of flow control or acknowledgment at all. 

3) Protocol Structure: Based on the previous observations, 
a two-layer structure is a very natural one for low-level pro¬ 
tocols in a local area network. The bottom layer should 
provide the basic function of delivering an addressed message 
to its (one or many) destinations. This level corresponds 
to the concept of a datagram network [28]. It should also 
take on the responsibility of detecting that a message has 
been damaged in transit. To this end it may append a 
checksum to a message and verify the checksum on receipt. 
.However, this layer probably should not take on the-respon¬ 
sibility of ensuring that messages are delivered, and delivered 
in the order sent, since different applications have different 
needs and requirements for these functions. The first layer 
might be implemented entirely in hardware; however, if the 
packet size, addressing structure, or routing topology of the 
hardware is not sufficient to provide adequate message size, 
process addressing, or broadcast selectivity, some software 
help will be needed to make up the difference. 

Above this first layer should be made available a variety 
of protocols. One protocol should support a virtual circuit 
mechanism, since a virtual circuit is definitely the appropriate 
model for a great deal of the communication that will go on 
in any network, local or otherwise. As alternatives to the 
virtual circuit protocol, there should be mechanisms for 
sending isolated messages, for message exchange communi¬ 
cation, and additional alternatives to provide support for 
message models other than the ones we have discussed here. 
For example, transmission of digitized speech requires a 
communication model with some but not all of the attributes 
of the virtual circuit; in particular, reliability is of less con¬ 
cern than timeliness of arrival. 

B. Applications of Local Area Networks; Higher Level 
Protocols 

In the previous section we considered low-level protocols 
for a local area network. These protocols exist, of course, 
to support higher level protocols, which, in turn, support user 
applications. In this section we "will consider a number of 
applications for which local area networks are suited. 

1) Access to Common Resources: The model of computing 
most common over the last few years is that of a large cen¬ 
tralized computer, with the only remote components being 
terminals and, perhaps, a few other I/O devices. Line control 
protocols such as SDLC [19] were created to serve this sort of 
arrangement. A simple but very important application of a 
local area network is to generalize this picture very slightly 
to include more than one central computer. As the total 
workload grows to exceed the capacity of a single machine, 
a common solution is to procure a second machine, and to 
divide the applications and workload between the two. The 
communication problem to be solved in this arrangement is 
simple but critical—to allow an individual terminal to have 
access to both of the central machines. A local area network 
can solve this problem, and provide some additional capa¬ 
bilities as well. For example, if the central facility has special¬ 
ized I/O devices such as plotters or microfilm writers, they 


can be placed on the local area network and made accessibl 
to both central machines—an advantage if a device is expensive 
and is not heavily enough loaded to justify having one f 0 ". 
each computer. Further, I/O devices can be placed remov 
from the central site but convenient to users; for examnl- 
a line printer can be placed near a cluster of users. 

This pattern of sharing among several computers can h, 
expanded to include more than just I/O devices. In f 2c . 
the network can be used to move computations from on' 
machine to another in order to spread the computina loa,' 
equally. The high speeds available in the local area network 
make this sort of load leveling much more practical [ban 
the bandwidths traditionally available on long-haul networks 

2) Decentralized Computing: A wide variety of new uvn 
for a local area network arises if the computing power avao 
able is not strongly centralized. .Let us consider the alternator 
of a computing environment consisting of a large number o’ 
relatively small machines, each dedicated to a small number 
of users or a small number of tasks. In the extreme, we ea.-. 
look to the future and imagine the day when each user hn 
a computer on his desk instead of a terminal. Such a com 
pletely distributed computing environment by no mear.i 
eliminates the need for an interconnecting network, to: 
users will still need to exchange information. Data bin 
containing the results of one person’s computation will ncr t 
to be shipped through the local area network to be usa! n 
input to other tasks. Users will wish to communicate wBr¬ 
each other by exchanging computer mail, as is now dorr 
over the ARPANET [29], Users will still want acce.y n 


specialized resources which cannot be provided to each user 
resources such as large archival storage systems, specialise 
output devices such as photo typesetters, or conneclm-. 
points to long-haul networks. All of these features can b< 
made available through the local area network. 

3) Protocol and Operating System Support: The applu.» 
tions outlined in the previous paragraph can be support! 
by high-level protocols very similar to the ones already 
existence in the ARPANET: TELNET for logging into i 


remote system through the network, and File Transfer P--' 
tocol for exchanging data between machines [26]. When- 
examines how these protocols might be modified to 
advantage of the special attributes of a local area net we-' 
for example, its higher speed, one discovers that the prec¬ 
is not one of modifying the protocols, but of modifying 
operating system of the hosts connected to the network 


that the services available through the network appear to 
a natural part of the programming environment of the °P'- 
ating system. The File Transfer Protocol in the ARP--'-'' _ 


for example, is usually made available to the user as 


an exp 1 ’-'-- 


command which he may invoke to move a 


file from 


machine to another. As part of this invocation he ma> ^ 
required to identify himself at the other machine, an F 
explicit file names in the syntax of the local and the lor 
machine, describing exactly what action he wishes to P er 
This particular view of file transfer has two disadvant* 
First, there is a lot of overhead associated with moving a 
Much of the delay in moving the file seen by the uSC [^ 
nothing to do with the time required to send the ( * ata .j u;< 
through the network, but is rather the time spent esta 
the connection, identifying the user at the other 
Second, the file system on the local computer un 4 ^ 

nothing about the existence of files accessible thro ^ 

network. No matter how sophisticated the local fh e s - 


lscence oi mes acccaruuix yjtc** 

how sophisticated the local fh e s - 


K et at.'- A 


terms of 


ch through 
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1 (tie process to receive the data is scheduled and requests 
1 u t, or b) the urgent pointer points to data not already 
3Reived by the process. In case b) an interrupt is sent to 
1 '. c receiving process, indicating that data should be read 
'j processed until the urgent pointer is past. The corre- 
^jnding mechanism in TCP required that a host be capable 
' '• understanding and responding to a special interrupt signal 
. jjie data stream, even if the signal had no meaning to the 
in it s particular application of TCP. The urgent pointer, 
is a simple mechanism that meets the needs of sophisti- 
. e( j host implementations without placing an excessive 
., ; den on unsophisticated hosts. 

'I Special Capabilities: The other aspect of low-level 
-utocols for local area networks to be discussed is the manner 
* . which protocols must be structured to take advantage of, 
•J provide to higher levels, the unique capabilities of local 
••.works. Conventional low-level protocols have provided 
function best characterized as a bidirectional stream of 
between two communicating entities—a virtual circuit. 
- ;e virtual circuit is implemented by a process that provides 
-fenced delivery of packets at the destination. While a 
vtual circuit is one important form of communication, two 
:,ers easily provided by a local network are very useful in 
.ariety of contexts. These are message exchange communi- 
,;ion, where the packets exchanged are not viewed as being 
umbers of a sequence of packets but are rather isolated 
gudianges, and broadcast communication in which messages 
1.-: sent not to one particular recipient but to a selected sub- 
,-:of the potential recipients on the network. 

a) Message exchange: A typical example of a message 
uhange is the situation in which one message asks a question 
•l another provides the answer. For example, if there are 
hrge number of services provided by nodes connected to 
local net, it is disadvantageous to maintain, on every node, 
[able giving all of the addresses of these, for whenever a 
nnge is made in the network address of any service, every 
■ie’s table will need to be revised. Rather, it may be ad- 
‘ctageous to maintain, as a network service, a facility which 
il take the name of a desired entity and give back its net- 
ork address. Clearly, the pattern of communication with 
a service is not one of opening a connection and exchang- 
js a large number of messages, but instead is a simple two- 
,‘-usage exchange, with a query of the form “What is the 
■dress of such and such a service?” and a reply of similarly 
Mple form. While a virtual circuit could be used for this 
"change, it is'unneeded and. uses, excessive resources. ■ 

1>I Broadcast: The example given above demonstrates 
:: need for a broadcast mechanism. If the service described 
'' ov e is intended to provide the address of network services, 
c* can we find the address of this service itself? An obvious 
r -ution is to broadcast the request for information. The 
:;; ry then takes the form “Would anyone who knows the 
dress of such and such a network service please send it to 
"‘•1" There are many other examples, some apparently trivial 
nonetheless very useful, for support of broadcast queries 
: 1 local network. A microprocessor with no calendar clock 
broadcast a request for the time of day. A new host 
Cached to the network for the first time may broadcast a 
I'usage announcing its presence, so that those who maintain 
i5 lcs may discover its existence and record the fact. Broad- 
** Mechanisms in the low-level protocols can also be quite 
^ U 1 in implementing higher level protocols for such appli- 
* lc) ns as document distribution to multiple host nodes, and 
* s Peech and video conference calls. 
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Why are these alternative models of communication not 
commonly found in traditional networks? The first, and 
perhaps most important reason is that long-haul networks 
have not been extensively exploited for applications in which 
computers directly query other computers with individual, 
self-contained queries. Instead, the major use of long-haul 
networks has been for long-term, human-initiated interactions 
with computers, such as direct terminal use of a remote 
computer, or long-term attachments of remote job entry 
stations. Such human interactions usually involve many 
message exchanges between sender and receiver, so that the 
extra delay and cost of initial setup of a virtual circuit is 
insignificant—perhaps even recovered by reducing redundant 
information in each message. As new applications such as 
distributed data base systems become more important, these 
alternative models will become important in long-haul net¬ 
works, but long-lived connections between terminals and 
host computers continue to dominate the usage. 

The second reason is precisely that discussed in the previous 
section concerning the relative simplicity of protocols for 
local area networks—a variety of functions performed in con¬ 
ventional networks are very difficult to understand except in 
the context of a sequence of ordered messages (a virtual 
circuit) exchanged between two nodes. For example, flow 
control is normally handled in network protocols by placing 
an upper bound on the number of messages which may be 
flowing at any one time between the sender and the receiver. 
This concept has meaning only in the restricted case where 
the sender and the receiver are a well-identified pair exchang¬ 
ing a sequence of messages. There is no obvious equivalent 
of flow control that can be applied to situations where sender 
and receiver communicate by sending arbitrary unsequenced 
messages, or where a sender broadcasts to several receivers. 
Similarly, if efficiency requires use of the shorthand version 
of an address for communication between the sender and 
the receiver, this clearly implies that the sender and the 
receiver have - negotiated this address, and agree to use it 
over some sequence of messages. Again, this idea makes no 
sense if communication is isolated in unsequenced messages. 

Another problem that is traditionally handled in the con¬ 
text of a sequence of messages is the acknowledgment to the 
sender that the receiver has correctly received a message. If 
messages are sequenced, acknowledgment can be very easily 
done by acknowledging the highest member of the sequence 
that has been successfully received. If messages bear no 
relationship to each other, then each must be identified 
uniquely by the sender, and acknowledged uniquely by the 
receiver. This increases the complexity and overhead of 
acknowledgment. However, in most cases where message 
exchange communication is the appropriate underlying com¬ 
munication model, no acknowledgment mechanism is required 
of the low-level protocol at all. For example, if a micropro¬ 
cessor system asks the time of day, it is not at all necessary 
to acknowledge that the query has been successfully received; 
the receipt of the correct time is sufficient acknowledgment. 
Similarly, a request for a network address is acknowledged by 
a return message that contains the desired address. Depend¬ 
ing on a low-level acknowledgment message to handle all 
failures can be dangerous, for it may lead to the practice 
of assuming that acknowledgment of receipt of a message 
implies that the message was processed at a high level. 

In the broadcast context, it is difficult to formulate a use¬ 
ful definition of acknowledgment that can be supported by 
a low-level protocol. What does it mean to say that a broad- 
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sive. For example, the ARPANET NCP host-to-host protocol 
[26] initiates a connection using a 56-bit (net, host, socket) 
identifier for the'uestination, but then goes through a nego¬ 
tiation so that instead of sending this 56-bit value on sub¬ 
sequent messages, a 32-bit (net, host, link) value can be sent 
instead. It is not clear whether this conservation of bits is 
appropriate even in a long-haul network; in a local area net¬ 
work, where bandwidth is inexpensive, it is clearly irrelevant. 
Other examples of ways in which extra header space can be 
used to simplify processing include: 

1) having a single standard header format with fields in 
fixed locations, rather than having optional fields or 
multiple packet types; field extraction at the host can 
be optimized, reducing processing time; 

2) using addresses that directly translate into addresses of 
queues, buffers, ports, or processes at the receiver with¬ 
out table lookup. 



Fig. 9. The urgent pointer mechanism. By transmitting a new 
value of the urgent pointer, a pointer into the data stream a s,.,T 
can indicate the data bufferred in the sender, network, and ret-' ' 
are holding up data that must be processed quickly. The receiver^ '' 
then adjust his use of the data stream flow control to process "is 
bufferred data until the urgent data is processed. The shaded area , r . 
dicates the location of potentially urgent data specified by a nariicui" 
urgent pointer value. . 


bj Simplified flow control, etc.: The low transmission 
delay inherent in local area networks, as well as their high 
data rate, can eliminate the need for complex buffer manage¬ 
ment, flow control, and network congestion control mecha¬ 
nisms. Consider, for example, flow control: the problem of 
assuring that messages arrive at the recipient at the rate it 
can handle, neither too fast, so that its buffers overflow, nor 
too slow, so that it must wait for the next message after 
processing the previous one. In a long-haul network, a re¬ 
ceiver typically allocates to the transmitter enough buffer 
space for several messages following the one currently pro¬ 
cessed by the receiver, so that messages can be placed in 
transit well before the receiver is ready to process them. 
Considerable mechanism is required to keep the sender and 
the receiver properly synchronized under these circumstances. 
In a local area network, the delay will typically be low enough 
for a much simpler flow control mechanism to be employed. 
For example, one can use the very simple strategy of not 
sending a message until the recipient has explicitly indicated, 
by a message in the other direction, that it is ready for it. 
In contrast, a network using communication satellites has 
such a high transmission delay that very complex predictive 
flow control algorithms must be used to obtain reasonable 
data throughput. 

It is crucial to understand that other factors may obviate 
these simplifications. While the data rate and delay char¬ 
acteristics of a local area network can render it essentially 
instantaneous, its speed cannot eliminate the intrinsic dis¬ 
parity that may exist between the capabilities of two hosts 
that wish to communicate with each other. These disparities 
may not show up when the two hosts are communicating 
through a long-haul network whose characteristics are so 
constraining that the principal problem is dealing with the 
restrictions of the network. While protocols for local area 
networks need not include mechanisms designed to cope 
with the limitations of the network itself, it is still necessary 
to design protocols with sufficient generality to cope with 
disparities between the capabilities of machines wishing to 
communicate through the network. Such disparities include: 

1) mismatch between the rate at which hosts can generate 
and absorb data; 

2) host delay between the time a packet is received and the 
time it is successfully processed and acknowledged: 

3) amount of buffer space available at the sender and the 
receiver. 


Further, considerable effort may be required to modify hue 
software to provide a suitable interface to the network. I: 
one were to consider the simple flow control mecharm::-. 
mentioned earlier, where a message is sent in the reverw 
direction requesting transmission of each message as it o 
needed, one would discover that in many cases the scheme 
was unworkable, not because the network introduced int, : 
erable delays, but because the hosts communicating v. i;:■ 
each other themselves introduced excessive delay. In a h:;,- 
host with a time-shared operating system, for example, i!-.,- 
real time that elapses from the time a message is receive.: 
one or more processes are scheduled in response to this mo 
sage, and that process runs, to the time a message is sent :r 
response, could well run into a large number of millisecond! 
milliseconds during which the other host is forced to wait. 

cj Example of protocol simplification: The low-loci 
protocol initially proposed for the Laboratory for Compute: 
Science Network at MIT is an example of the sort of proto--: 
that results when simplicity of mechanism is a primary desiyr 
goal. The Data Stream Protocol (DSP) was based on the 
Transmission Control Protocol (TCP) used in internetworks: 
experiments sponsored by the Defense Advanced Re-sea:- 
Projects Agency [27], but evolved from original TCP due t. 
the continuing desire to simplify the protocol features, packet 
formats, and implementation strategies. Most of these simr !: 
fications have subsequently been incorporated into the TCP 
One specific example is the mechanism used to signal ir.ic 
rupts and other urgent messages that are logically part ol C- 
sequence of data in a virtual circuit. The basic model is tba¬ 
the sender occasionally wants to signal the receiver that J- 
data in the stream preceding the signal (buffered sonKwdK-- 
in the network) must be scanned immediately in order '■ 
respond promptly to some other important signal. A nie«.ha 
nism is provided whereby a pointer into the data stream =* 
maintained at the receiver, which can be moved, when ■■■- 
sender chooses, to point to a more recently transmit^'" 


piece of data. This pointer, called the urgent pointer. 
be used to indicate the point in the data stream beyond "h 1 2 3 --- 
there is no more urgent data. (See Fig. 9.) The urgent point'- 
can be implemented in two ways, depending upon the natn- 
of the host receiving the message. In the case of a sirnfl 
(e.g., microprocessor) host dedicated to a task that P roCCS ^ 
the incoming stream as it arrives, the host need not P r0 ^ ( 
the urgent pointer, since by design, all data, urgent or n 
are processed as quickly as possible. In contrast, on a ^ 
time-shared host, data need not be processed until ei 
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etal.: AN INTRODUCTION TO LOCAL AREA NETWORKS 

. phe basic design principle of the transceiver is that it must 
, f esent a high impedence to the bus except when it is trans¬ 
mitting and actually driving the bus. This is essential to the 
operation of the contention bus network; a large number of 
reivers on the bus must not present impedence lumps or 

any way interfere with a transceiver which is actively 

-ansmitting. 

The receiver must be able to detect and properly receive 
jjnals from the most distant point on the bus; in addition, 

; must be able to detect a colliding signal while its companion 
..jnsmitter is itself driving the bus. This requirement impacts 
.j,e choice of an encoding scheme for data transmitted on 
.jje bus. A number of data encoding schemes can be used, all 
,f which require that the transmitter be able to place the 
pansmission medium in two distinct states. At first glance, 

: might seem that three states could be used: the quiescent, 
•igh-impedence state, to indicate that no transmission is in 
-togress, and two active driver states, for example +V and 
r. However, with two active driver states, when two or 
more network nodes attempt to transmit simultaneously, 
pe cable will be driven to different voltage levels at different 
mints. This has two effects. First, it places a severe load 
n drivers. Second, it makes the detection of a colliding 
,:gnal more difficult than it needs to be. On the other hand, 
the transceiver drives the cable to some voltage to represent 
jne signaling state, and represents the other signaling state 
vj not driving the cable, the problem of overloaded drivers 
a eliminated, and the task of collision detection is greatly 
simplified. Collision detection is accomplished looking at 
the bus during the transmitter’s quiescent state. Any signal 
,’resent during that time must come from another transceiver, 
ind constitutes a collision. The transceiver can detect an 
morning signal with 20-dB attenuation, which corresponds 
uabout 1 km of the particular cable used. 

The transceiver must be able to cope with ground potential 
references at the various network hosts. Isolation is accom- 
rlished by high-speed optocouplers and an isolated power 
upply which enables the major circuit elements of the trans- 
river to be referenced to cable ground, rather than local 
rest ground. Finally, the fault detection, or watchdog 
arcuit examines the output of the driver to guard against 
rransceiver failures which drive the bus and disrupt the net¬ 
work. The signaling states used by the transceiver result in 
be driver being quiescent approximately 50 percent of the 
,;me l if the driver remains on steadily for several bit-times, 
is deemed to. be faulty, and the fault detector disconnects 
‘i power, which, of course, returns the driver to its high- 
- 11 Pedence state. 

Complexity of the Local Network Interface: In its 
-resent form, the LNI comprises about 350 TTL SSI and 
^[integrated circuits, apportioned as follows: 


PDP-11 full-duplex DMA 
Name table controller 
Name table cells (8 provided) 
Network-oriented portion 
Test and diagnostic 


of the sigitfj^ "be count of 120 chips for the network-oriented portion of 
Sir 5 exc i u di n S the associative name table, is well within 
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the capabilities of current large-scale integration. As the 
field of local area networking matures, and standards are 
arrived at, it is likely that integrated circuit manufacturers 
will add local area network controllers to their product lines, 
to take their place alongside other LSI data communication 
chips which are already available, making high-performance 
local area network technology available at a very reasonable 
cost. 

V. Protocols for Local Area Networks 

As in long-haul networks, local area network protocols 
can be divided into two basic levels-low-level protocols 
and high-level protocols. At each level, the characteristics 
of local networks impact effects on protocol design and 
functionality. 

A. Low-Level Protocols 

The term low-level protocol identifies the basic protocols 
used to transport groups of bits through the network with 
appropriate timeliness and reliability. The low-level protocols 
are not aware of the meaning of the bits being transported, 
as distinct from higher level application protocols that use 
the bits to communicate about remote actions. Two aspects 
of local area networks have a very strong impact upon the 
design of low-level protocols. First, the high performance 
achievable purely through hardware technology enables the 
simplification of protocols. Second, low-level protocols 
must be designed to take advantage of and preserve the special 
capabilities of local networks, so that these capabilities can 
be utilized, in turn, by higher level application protocols. 
We will explore these two issues in this section. 

11 Simplicity: Local area networks must support a wide 
variety of hosts, from dedicated microprocessors to large 
time-sharing systems. The existence of extremely simple 
hosts (such as microprocessor-based intelligent terminals, 
or even microprocessor printer controllers) leads to a desire 
for simple, flexible, low-level protocols that can be econom¬ 
ically implemented on small hosts, while not compromising 
the performance of large hosts. Supporting a variety of hosts 
also leads to a difficult software production and maintenance 
problem that can be ameliorated somewhat by having a. 
protocol that is simple to implement for each new kind of 
host. Although quite a variety of hosts has been attached 
to long-haul networks such as the ARPANET, the problem 
of software development has not been too severe, since each 
individual host in such environments usually has : a software 
maintenance and development staff. In the local area network 
context where a variety of computers are all maintained by 
a small programming staff, the arguments for simplicity in 
protocol design are far stronger in our view. 

In a long-haul network, complexity results from strategies 
that attempt to make as much of the costly network band¬ 
width as possible available for transport of high-level data. 
The costs of a local area network are concentrated instead 
in the host interfaces, the hosts themselves, and their soft¬ 
ware. Two factors lead to the simplicity of low-level local 
area network protocols. 

a) Unrestricted use of overhead bits: Bandwidth is in¬ 
expensive in a local area network; there is little motivation 
to be concerned with protocol features designed to reduce 
the size of the header or overhead bits sent with each message. 
This is in contrast to protocols developed for networks making 
the more conventional assumption that bandwidth is expen- 
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of a message. In a contention bus or contention ring network, 
the output machine may transmit only when the network 
is quiet. The “token present” signal is replaced by a “network 
quiet” signal. In the ring network, the reception control 
section signals the transmission control section if it detects 
another token in the midst of its receipt of the message the 
transmission control section sent; this has its analogue in the 
collision detection capability of the contention network. In 
both cases, the LNI must abort transmission of its message 
and take corrective action. In the ring network this is an 
error condition, an exception; more than one control token 
is present in the ring. In the contention network, a collision 
is an expected event. Both situations can be handled by the 
LNI reporting the event to host software, which can attempt 
to restart a token on the ring, in the ring network case, or 
apply a retransmission backoff algorithm in the contention 
network case. 

A better solution for the contention network is to modify 
the transmission control section to execute a simple retrans¬ 
mission backoff algorithm in hardware. This requires that 
the entire message remain accessible to the transmission con¬ 
trol section without host intervention. The FIFO buffer 
cannot be used in this situation; a complete packet buffer 
which is not erased until the message has been successfully 
transmitted is an appropriate alternative. 

Two features of the ring network LNl’s transmission con¬ 
trol section are not needed in the contention bus network 
version: the data repeater which passes bits from the receive 
side of the LNI to its transmit side when the LNI is not 
transmitting a message, and the token generator which 
places a new token or connector onto a quiescent ring. Of 
course, the connector is'a brief sequence of bits, and there 
is no good motivation to delete it from the beginning of 
messages transmitted by the contention bus version of the 
LNI. In fact, retention of the connector at the head of a 
message results in fewer changes to the input machine of 
the LNI. It can use its token/connector detector to signal 
the beginning of an incoming message. Its function remains 
the same, for the most part; extra connectors detected in 
the middle of a message indicate a collision, just as they do 
for the ring network version. However, in the contention 
bus network, because bits are not repeated from one LNI 
to another, there is no way to set the match/accept bits for 
the benefit of the transmitting - LNI, and the match/accept 
field of the message cannot be used. 

The signal conditioning section of the LNI undergoes an 
interesting transformation. For a contention ring network, 
of course, the signal conditioning section remains the same. 
However, for a contention bus network, the logic levels of 
the LNI must be converted to appropriate signal levels and 
waveforms for the coaxial cable of the bus. This is done in 
a two-step process. First, a cable transceiver is added to the 
configuration. To minimize impedence mismatches, reflec¬ 
tions, etc., the transceiver is located immediately adjacent 
to the network cable, and is often packaged separately from 
the LNI. 4 It is connected to the cable either directly, or via 


’This has become common practice in local area networking; the 
networking transmission medium is generally not brought into the 
racks, equipment bays, etc., of a host computer where it would be 
subject to accidental disconnection and other physical abuse that 
could disrupt the entire network. Instead, the connection point for 
a host is designed to be physically stable: a box on the wall, above 
a false ceiling, etc. 





Single ground 
point for entire 
coble - 


Fig. 8. A typical bus transceiver. The opto-isolators and isolatrd p"*" 
supply permit the drivers and receivers to be referenced in 
ground; the cable, in turn, is grounded at only one point alnru :■» 
length, eliminating problems that would result if each transcend 
the cable to local host ground. 


a short stub cable attached to the main cable via a tap. b»N» 
ond, since the transceiver is located adjacent to the no t 
bus cable, and the LNI is located next to its host, an arr"’ 
priate transmission scheme must be selected to span ’'■> 
intervening distance. For distances up to 30 ft or so. 'm - ; r 
ended” drivers and receivers will suffice. For better rcliaN. 
greater distances, or both, differential signals over a slm--.-'’- 
twisted pair can be used—just as in the transmission nun-:- 3 
of the ring network itself. So, the signal conditionings^ 
of the original LNI can be modified to interconnect tliv I s 
and the cable transceiver. 

4) The Cable Transceiver: The care taken in the 
of a cable transceiver for a contention bus network 
strongly influence the overall reliability and perform-*-' 
of the network. Therefore, we conclude our case stuJ> 
examining a hypothetical contention bus cable transvco--i 

designed ami b |U! ' 


shown in Fig. 8, that is similar to one 
the CHAOS Network at the MIT Artificial Intelligent 


tory; it is typical of transceivers built for various 
bus networks. 

The cable transceiver performs the following functions 

1) transmission (cable driving); 

2) reception; 

3) power and ground isolation; 

4) collision detection; 

5) transceiver fault detection (“watchdog”). 

The first three of these constitute part of the sign- 1 * 
tioning function described previously. 
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